bambooliner.blogg.se

1. #CREATE XML NOTEPAD HOW TO#
2. #CREATE XML NOTEPAD MANUAL#
3. #CREATE XML NOTEPAD SOFTWARE#
4. #CREATE XML NOTEPAD CODE#
5. #CREATE XML NOTEPAD FREE#

#CREATE XML NOTEPAD CODE#

You can only do so much with code snippets and samples.

#CREATE XML NOTEPAD HOW TO#

The purpose of the project was to show folks how to use System.Xml features. InfoQ: Why did you decide to release the source code and design document? But we also did a number of "bug bashes" to get people really using it like a customer would and this finds a different set of bugs, more in the usability area, and we got a lot of feature suggestions which also helps us figure out if the product is "complete" from a feature set point of view. This is a methodical unit testing approach which finds lots of bugs in edge cases and so on, and you look at the "code coverage" report to see what you haven't thoroughly tested yet and so on. There is a suite of automated tests included in the XML Notepad project that uses the Visual Studio Team System Unit Test project, which I love by the way.

#CREATE XML NOTEPAD MANUAL#

InfoQ: For this project, would you say you focused more on automated or manual testing?īoth. Breaking down the barriers also makes for a much healthier team – so there's a lot of side benefits to Agile that I see. Later on in the project we'll have the devs doing test work to help make a dent in the test debt that has built up due to churn in the product. This is really a development role for the test team. Early on the test team will be doing test infrastructure development, talking with development on the kinds of things they'll need to be testing and making sure they are ready to do that. The best way to manage this is to break down the barriers between development and test. For example, when last month's tests are all broken because of the amount of churn in the code this month.

#CREATE XML NOTEPAD SOFTWARE#

InfoQ: Do you see this changing the way you test software as well?Īgile development does impact test a lot, with a highly iterative process things change a lot, and change is very hard for the test team to track and deal with. So a better example might be GUI design which only applies to those components that have a GUI, these teams will put extra process in place to ensure they have the best possible GUI design. For example, if one team is doing a performance critical piece, they will do a lot more around monitoring the design, implementation and test progress on that performance axis – this actually is not a good example because every component has to perform or else the whole system sucks.

#CREATE XML NOTEPAD FREE#

But even there each feature team is free to add more process that is specific to their project. Massively parallel development on large projects is just plain hard, so we generally have to put a lot more process in place to help manage that. Generally at Microsoft the process is there to serve the team, the team is empowered to make the process work for them not the other way around. To be honest, it is what we've always been doing on this kind of project, we just have an official name for it now. InfoQ: Compared to how you used to work, does this process seem to work significantly better or is it just different? There's no reason why a single feature of a large product can't be thought of as one of these smaller application efforts. The interesting thing is we're trying to move all product development to this sort of agile model. This monthly cycle seems to work really well. This checkpoint stops a project from going off into the weeds too badly. Bigger changes in resourcing or direction for the product can happen at this point. At the end of each month we do a "showcase" meeting where results of the work are presented to management, and then planning happens for the next month. Jointly the feature team has a high sense of ownership over the product. Specifically we do one month iterations with a "feature team" consisting of developers, program managers and testers (3-10 people in all). So it's a light weight process with a small team that can move fast and respond quickly to feedback. We prototype the idea, show it around, get feedback, lots of hallway discussions, great feedback gets incorporated into the next iteration and so on, until we reach the point that we think we have the right set of features to call it done. We're using an " Agile Development Process" for these kinds of tools, which means it's a highly iterative process. InfoQ: What development process did you use to create XML Notepad? The interview is about software development processes used to build the product (see also Microsoft countingon Scrum and XP), not about Notepad itself.

XMLNotepad is a free XML editor written in C# with features like a search tool that supports RegEx and XPath, an XSLT transformation results view, and a schema validator. Following up on our coverage of XML Notepad's rebirth in Sept, InfoQ had the opportunity to interview Chris Lovett of Microsoft's XML team regarding XML Notepad and its development process.