As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have had great success e.g. with fast development cycles and continuous integration.
However, I think pair programming or continuous customer communication are less useful due to issues specific of embedded software programming.
What do you think? What are the most useful agile practices on embedded software development?
I would have to disagree. I've done it, and about 10 years ago I co-founded an agile coaching company specializing in embedded (we're no longer a company but the website is still up with several useful resources). I recently helped another company adopt agile for their embedded project, and it worked very well for them.
Agile practices like short iterations, pair programming, and frequent communication with the customer are even more important with embedded software because there's more at stake, both because embedded systems are usually harder/more expensive to update in the field, and because they are often used in mission-critical applications.
As for pair programming, if your company only has one person that knows the first thing about a component of the software, that's a huge risk, and pair programming is a great way of doing cheap knowledge transfer. Both developers don't have to be experts in that part of the code. You can have a primary that is and a secondary who isn't. The secondary partner is able to offer help on program structure, compare design decisions, ensure proper testing and documentation, etc. Of course each developer has to be a primary sometimes and secondary other times to make the crosstraining effective. This is also a very effective way of bringing new developers up to speed on your products.
Lastly, customers care about features and plans, not code. Embedded doesn't change this. Showing off what you have so far and what you plan to do next ensures you're working on what you're supposed to.
Embedded software development is no different then normal software development, therefore you can use every agile practice you find useful.
Concerning pair programming, I look at it as a code review on steroids. If your company can afford enough SW engineers, I don't see a reason why it could not be used for embedded software development.
by the way, what exactly do you consider under "issues specific of embedded software programming"? I do not have experience in non-embedded software development, and I do not see how it could be different.
It is not obvious to me the value of Agile in many applications.
Many applications, including embedded applications, often include standards based protocols or technologies. You download or buy the specification, you implement the specification, testing as you go, and then you are done. What would I do at my daily standup, "Um, today I read pages 1 through 9 of the standard, tomorrow I plan to read pages 10 through 17". How does standards based development benefit from Agile? Quick response to changing customer input, um, no. The standard doesn't change from day to day.
If Agile software really means "training" then paired programming fits. As pointed out above unless you can afford exactly double the number of engineers it is likely you will have different specific skill sets among your engineers. In a large organization with many engineers with overlapping duplicate skills maybe you can pair engineers efficiently. In a smaller organization how does that work? Unless it is actually paired training, then ok. Sounds expensive though.
Often a huge amount of infrastructure is required just to host or deploy the smallest amount of first pass functionality. How might I do test driven development for an embedded flight controller, or automotive engine controller? Years of effort are required just to get the infrastructure in place to host a test. I certainly don't want the rest of my designers and engineers sitting around idle waiting for the test infrastructure so they can do TDD. I need standards driven development while waiting for many of the pieces to come together.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am going to look for a job as a software tester (a SDET maybe), especially for website test. I have some vague impression of this area and got a couple of specific questions as below:
Among so many documents, such as functional spec, design spec, which should I pay more attention to? How to view them in a tester's view?
Any good suggestions about writing test spec?
Any attention should be paid to website test?
These are just some questions I got now, I'll update with more shortly.
I'd like to hear your voice very much. Many thanks.
Credentials: I'm an SDET with 5 years of experience, 2 of those years testing web applications.
1- I'd say testerab has a pretty good answer. There is no single document that you can invariably rely upon across companies or even teams within a single company. Pay attention to whichever document has information.
I'd augment that answer with this advice: Don't be surprised if the documentation is insufficient. Strike up strong relationships with people who help define the product (the dev, the business owner, the program manager, etc.). You will nearly always be relying on them for some of your specifications, since it is difficult to cover everything on paper (and, as you gain expertise as a tester, you will learn to see things that others don't notice). Try to write down any "verbal specs" as you hear them, and ideally get any requests for specification clarification in writing or email. Gathering them all in a public document is wise, and may help to uncover if two people have very different ideas about what the spec "ought" to be.
2- Testerab has a good answer to this question, also, here: How Do You Keep Automated Tests in Synch With Test Plans
"1) Who reads it? 2) Who should probably read it, but currently you suspect they don't bother? (Do you know why they don't bother?) 3) What information do they need to get from it? Does it give them that info? 4) How do you currently present that information? Does that work for your readers/non-readers? 5) What sort of feedback do you need to get from the readers of your test plan? 6) Do you have any regulatory requirements that you need to satisfy with your test planning? "
Test plans, like product specs, will vary greatly depending on the needs of your group. If you are in an Agile group you may spend very little time on your test plan, doing little more than outlining the areas you need to cover - or you might not even have a test plan at all, but just a conversation with the team about what will be sufficient testing for everyone to feel confident about making decisions about the product. Other companies will have very specific guidelines you will need to follow.
Cem Kaner's classic book "Testing Computer Software" is slightly outdated, but still a good place to start and discusses test planning. I'd recommend you buy a copy quite strongly, unless someone can recommend something as authoritative that is more current. Last I heard, this was still the software testing book.
3- I'm having a little trouble understanding this question, but will do my best. Do you mean, what specifically will you need to know to test websites? First, what do you mean by websites? Do you mean web applications? If so, you will probably need to understand server / client architecture, web services, databases and basic SQL, at least rudimentary security testing, integration testing, functional testing, and will benefit from an understanding or specialization in performance testing, load testing, more security testing, and familiarity with web GUI testing with Selenium or Watir.
Some helpful things for us to know to help you get started:
How much experience do you have, both as a developer and as a tester? If you are just getting started in your career, what is your educational background?
How much experience do you have working with web applications, and in what roles (dev, test, PM, etc.)?
And, you might want to try asking some of these questions over at http://www.softwaretestingclub.com - this is a site for software testers to build community. You will get a lot of good advice and support there, so long as you are active in the community, and many of the most influential software test writers hang out there. If you do stop by there, feel free to look me up!
Hope this helps!
Edit: Added some info to answer q. #2 and to mention Cem Kaner's book.
I'm a developer with 2 years .NET experience and 1.5 years previous testing experience and an ISTQB/ISEB Foundation qualification.
To answer your questions:
1: A test manager will (typically) have a test plan and awareness of the specification documents to be tested against. Using what a developer is using is a good start. If the development methodology is agile this will probably be "user story".
A good way to look at the documents is to go through and look at where individual elements of functionality are specified and create steps to exercise them (see some of the functional techniques below).
2: What do you mean by "test spec"?
You will need to prioritise the areas of the application that need testing and understand the coverage needed. A "Test case spec". (or test script) will fit into higher level documents (like Test Plans, and Test Strategies) can be efficiently and effectively written using some Black box (Functional) techniques including:
Equivalence Partitioning,
Boundary Value Analysis,
Decision Tables,
State Transition analysis,
Use Case analysis (which could be based on a user story)
to come up with scripts that contain test cases. These techniques can be looked up online.
White box (Structural) testing involves an awareness of the code and includes:
Statement Coverage,
Decision coverage
If you're are looking at a website, this may involve JavaScript; QUnit is a testing framework for automating JavaScript testing and would be useful to research. NUnit is a commonly used test framework for .NET applications (including web applications) - NUnit was ported from its Java equivanlent JUnit and has been expanded (most probably owing to the popularity of .NET).
3: I don't understand what you mean by this? A web application will need to be tested in many different ways, and contains server and client functionality that will be tested using different techniques and the testing needs will need to be analysed. It will depend on the project.
As mentioned in other answers there are also other types of testing:
Unit - modular testing of functions at the lowest possible levels
Integration - testing functionality between different functional areas
Regression - testing to ensure that previously working functionality hasn't been broken by changes
System testing (Functional) - ensuring that the code/system under test is working as specified
System testing (Non-functional) - ensuring that aspects of the system that may not be specified are appropriate e.g. performance, load, stress, interoperability, maintainability, reliability, portability, usability
Acceptance (something called User Acceptance Testing or UAT) - ensuring that the system under test is fit for use
As mentioned in other answers, you will be retesting existing defects and inclusion of these to your test scripts is a good idea.
Hopefully this answer has given you a lot of food for thought and a good base for research. Testing qualifications or a role as a Junior Tester in an established team to build your understanding and experience could prove to be very useful.
"Among so many documents, such as functional spec, design spec, which should I pay more attention to? How to view them in a tester's view?"
Being able to extract useful information from many different sources of documentation is a critical skill for a tester, so you're right to identify that as an area you need to look at. The documents you need to look at will vary from project to project, and from company to company, so there isn't one good answer about what document you need to look at - but having good specification analysis skills will mean you'll be able to cope with whatever you're given.
For that, I'd strongly recommend this BBST course on specification based testing - it will show you how to analyse specifications, applying the Satisfice Heuristic Test Strategy model. That should also help you with your second question about writing a test spec.
http://www.testingeducation.org/BBST/BBSTSpecificationTesting.html
I'd recommend the BBST courses in general - the course materials are all available freely online, at the website above.
If you're really serious about testing, you should also consider taking the online course from the Association of Software Testing. The Foundations course is free to members, and you'll get the opportunity to practice your skills online, gain really valuable feedback on how you present yourself and your ideas, and you'll also meet a lot of outstanding testers, both as fellow pupils and as instructors. It's hard work - but if you're willing to put the effort in you will really get a tremendous amount out of it. Being able to discuss the basics with other people will really help you to get a deeper understanding.
my 50c
If you don't have test specs, or any kind of specs, you can transform your bug reports into test plan.
For each bug report that occurs, create one test item. That way - you'll have list of tests that you can follow when doing regression testing.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I work in a small company (2-4 software developers) where software is "only" a part of the main product (specialized measurement instruments). So far the software has been built from start to end with no formal process at all, but as we're steadily growing in both in number of products and people involved, it's evident that we need to adopt some kind of methodology for the whole thing (designing, building, testing, maintaining) to avoid blowing into a mess
The problem is that none of us has much real-world experience on such processes. Wikipedia's software development methodology and software development process entries list lots of practices, and I'm aware of the modern buzzwords (agile, extreme, etc.), but we're still lost on how and from where to start all this.
What should we do to get started, given that currently we have no formal process, and the goal would be to have a light process that helps us keep things under control without slowing us down? Is there some:
Essential de facto literature that we should read first?
Essential tools? (We do have a SCM, but should we start using something like FogBugz?)
Practical "do this and this" guidelines?
Any guidelines are welcome, as long as they're not 1000+ page books! I want to avoid both the religious hype and the dull academicity that seem to surround this field, and find out what to do in practice.
Highly recommended reading includes : The Agile Manifesto and The Pragmatic Programmer. Subsequently, you'll probably want to get familiar with Scrum software development, or Test-Driven Development. At the very least you should have:
Source Control repository
Bug tracking system
Standard set of tools
for communication (A wiki tends to be
popular for documentation, these
days),
IDE
Testing framework
A lot of things will depend on the skills of your team and the application domain that you're seeking to go into. Get yourselves familiar with some methodologies, then practice them. Have 15 minute standing meetings at the start of the day. Develop code incrementally with a write a failing test, make it pass, repeat mindset. Etc etc.
I would suggest to try Scrum for start. As lightweight project management framework it should suite your small team needs.
To do that less painful I would also suggest temporary hiring someone familiar with scrum (certified scrum master maybe), after 3-4 months you should be able to keep it running by yourself. Really investing in few months of experienced team member should pay off. And I don't mean analytic, consultant or whatever you call person that comes, analyzes, makes presentation, takes money and goes while you stay with a problem. I mean Team member that will work with you but also introduce scrum to you via daily practice.
You could also just read some books instead, or send one or two team members to a training, but I think that having someone to incorporate Scrum into your daily work and start learning by examples is the best.
Good description detailed description (based on daily work) would be Scrum and XP from the Trenches (alternative source).
Subscribing rigidly to someone else's view of the development process isn't going to work for everyone. Start with the real basics
Get the basics of the development process right - see The Joel Test.
Track everything. Use a system like JIRA, FogBugz or so on to track all issues, features and bugs that are ever reported. Track how long you spend on each task; the information you have the better prepared you'll be.
Triage - Work with stakeholders to make sure what you are doing is actually important, rather than just what you think is important. In my experience, developers and customers often have wildly differing views!
I'm a huge fan of the recent Lean literature by the forerunners of the movement, Mary and Tom Poppendieck:
Lean Toolkit
Implementing Lean Software Development: From Concept to Cash
Leading Lean Software Development
These are very practical books that look at the whole business value chain from a software team's viewpoint, instead of being head-down in software land and ignoring business goals.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Jeffery Palermo says 'Classic WebForms More Mature Than ASP.NET MVC': "Is Classic WebForms More Mature Than ASP.NET MVC?".
It seems to be subjective, but what I want to know is, what exactly "mature" software is?
The answer is very subjective. But basically if the software can answer to most of these criteria (in no order of importance):
secure
reliable
actively maintained
has active community
field-proven
Then it can be considered "mature".
It is important to note that different clients would expect different levels of "maturity". A large corporation would demand that the software it uses is secure enough to protect its sensitive data, and that the software is supported by a support rep available 24/7. As opposed to a small private project of your own which you might care much less about security, and you do not need (nor can afford) a service package which includes 24/7 customer support.
So ,maturity differentiates according to the client, but the basic criteria remain the same.
Mature is when people have figured out how to deal with it.
(And we're talking about development platforms not about end-user apps, aren't we?)
For example, javascript only became mature with the introduction of prototype, jquery and the like.
Before that, people tend to code strange things they they'd regret.
So you're asking for subjective opinions on a subjective topic. :)
I would say, mature would add the following characteristic to a technology:
People know how to use it, know its possibilities and limitations
People know what the typical usage scenarios are, patterns, what are good usage scenarios for this technology so that it shows its best
People have found out how to deal with limitations/bugs, there is a community knowledge and help out there
The technology is trusted enough to be used not only by individuals but in productive commercial environment as well
Reduce Subjectivity by Developing a Measuring Tool for yourself.
My Criteria are for Business Software:
Feature Rich - handle lots of Business Rules
Flexible - Selectable Features via Parameters & Configuration
Stable - Few, if any bugs causing malfunction such as crashes
Well Documented - User and technical Documentation
User Friendly - as attested and recommended by users
Robust - Not very much fazed by events such as power failures and erroneous user input.
Installs & Runs "out of the box".
Take all the Criteria and place it in a spreadsheet with columns rating from 0 - 5 and do a rating by ticking the column corresponding to your rating of each criteria.
If overall score is 25 or better then the software is mature.
If the score is 15 to 24 then the software is average.
If below 15 then the software is immature.
Mature software has to be whatever you mean it to be. I don't think you will find an easy mechanism for measuring maturity, and everyone's definition is going to differ anyway.
It's always going to be a subjective view I'm afraid and therefore subject to a lot of argument.
I would say that mature software is stable, well documented, widely used and well tested.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am going to change my working sphere from Enterprise Web Applications written for concrete business process to Public Web Sites that will be accessible to all users around.
What is difference between this two spheres at the most top level? What specific characters I need to know about modern web sites development?
I suspect one could write books about this.
I suppose the first difference is the user base. With an enterprise, you can, at least partly, ensure the users are doing what they are supposed to - and if not you know who they are and where they live. Further, they can be fired for abuse. On a public web site, you almost have to assume that some part of your user base is not there for a positive reason. So be paranoid - if they're not attacking you yet, just wait.
A second related point is that users will find ways to use (abuse?) your site you never thought of. Plan for the worst, hope for better.
Third, language, culture and usage varies across the world. A form, for example, with "zip code" that accepts just 5 digits may make sense in the US but is useless in the UK. And asking for a state and restricting it to two characters likewise makes no sense say in Italy where Italy IS the "state". This also applies to actual content - that joke you think is so very funny may be offensive in other countries. And never under estimate the ability of some folks to be offended at anything.
Fourth - get a good bunch of beta tester and test your site, and updates, carefully and thoroughly.
Fith, have a plan for scalability - if you suddenly get "discovered" can your site take the traffic.
That's 5 things at least.
In an enterprise application, functionality and efficiency trump aesthetics every time. This is because you have a captive audience. The people who use your application are being paid to use it.
However, when opening an application up to the public, aesthetics becomes more important. There are always alternatives, and a given person will be more attracted to the application which looks better. Granted, functionality is still very important for repeat users, but you won't get people in the door if your application looks amateurish.
Browser agnosticism - In enterprise apps, it used to be that the developer would target the app at a specific browser, just for simplicity's sake.
In internet accessible apps, the developer must target the vast majority of browsers. While this has gotten easier in the last few years, it is still a issue that needs attention.
Scalability - its easier to scale an enterprise app, its easier to predict the growth of usage of the app, or simply design for access by all users in the org at once. This is not generally the case for internet sites. The day you get slashdotted, or dugg is the day that you learn this. Better to design scalability in from the start, rather than have to learn it at the time that your site starts to suffer.
In addition to Zack's answer, I would say that a web site/application that is open to the public needs to be constantly evolving/refreshed in order to grow your user base and keep them. Whereas on a more closed system, consistency and reliability are key priorities.
Depending on the nature of the application, if it has significant amounts of content Internationalization and presentation of content are hugely important.
As Zack mentions, public users have a lot less tolerance for poor UI than enterprise customers do. That said, public users are more tolerant of incremental change; you can upgrade a live site as you feel like it (as long as it works, of course!!) without having to go through endless feature-request prioritization committees and user-training requirements.
Public web sites needs to be easy to use. While it's important that they look somewhat polished, don't ever let polish get in the way of ease of use. For example many designers like fixed width layouts because they are more predictable, many users like fluid width layouts because they use the space more efficiently. Side with your users.
Enterprise users can be forced to deal with needlessly-complex systems (lord knows I am more than I'd like), the general public cannot.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
After reading Wolfbyte's answer on Enterprise FizzBuzz I have thought about what constitutes a program as "Enterprise".
What makes an application or a software development process as Enterprise?
EDIT: It seems like there is a lot of negativity around the word Enterprise.
Are there anyone who actually enjoys writing Enterprise-Level applications?
What "enterprise-level" really means is:
Compatibility with architectural schemes and long-term technical plans that overarch anything you or your team will ever do, and thus cannot be changed.
Conforms to governance requirements
Expensive to build and maintain ;)
Has the following qualities:
Maintainability
Scalability
Functionality
Reusablility
Reliability
Understandability
Usability
Modifiability
Testability
Portability
Efficiency
Flexibility
Modularity
Interoperability
As far as "enjoying" writing Enterprise-level apps, it can be difficult to do so because one of the characteristics of an enterprise system is that it's larger than any one person. People usually enjoy their work because they can take ownership of it, but enterprise development isn't really "owned" in that sense, rather it's "produced" through a rigid, complex project path guided by acceptance gates and steering committees and business project owners.
Think about all the things that you, as a programmer, care about in a software product.
Now think about all the things that you, as a user, care about in a software product.
Now forget about all of those things. Enterprise software isn't purchased by users or programmers. Requirements like "intuitive", "fast", or "interoperable" just don't apply.
Instead, they must meet requirements such as, "vendor published big fat whitepaper full of words like 'fast', 'intuitive', and 'interoperable', so when the peons complain that it makes their jobs more difficult we have something to point at while writing 'difficult' into their employee records".
Slow. Hard to use. Expensive. Based on obsolete technology. See the rails plugin "acts_as_enterprisey"
I kid.
Seriously though, it generally refers to things written for use by Fortune-1000 types, where there are large numbers of users and complex business rules.
If you're an ordinary developer, it's anything bigger than what you're working on now.
If you're an architect, it's the stuff you did at the last client.
If you're the CIO, it's all the stuff that "really matters" -- the stuff above baseline, keep-the-lights-on operations.
If you're in sales, it's what you're bidding on.
If it's your product, of course it's enterprise-ready. You just spent a year making it "scalable" so it would grow to support "the enterprise".
If it's open source, of course it can't be enterprise-scale. Nor, for that matter, is your competitor's product.
And, of course, it varies by client. For the $1B per year companies, a few Oracle financial reports was an Enterprise Initiative. For a Fortune 100 company, almost nothing is really "enterprise" because the entire enterprise is so big and globe-spanning that it's hard to comprehend any one thing that actually fits all the nooks and crannies of that conglomerate business.
Usually Enterprise is used in the negative. "Your software/service/product/offering isn't enterprise ready" or "Open source isn't suitable for enterprise computing".
An Enterprise Application usually something that has multiple tiers and runs on many machines and is designed to fulfill the needs of an larger organization. In practice it usually has a database backend, business logic middle tier, and some kind of frontend like a web interface. Likely has performance and high availability requirements, as well as backup, logging, auditing, and authentication.